1. Field of the Invention
The invention relates to computer software used to interface Java.TM. code to hardware or non-Java code. ("Java" is a trademark of Sun Microsystems, Inc.) More particularly, the invention relates to a method for generating interface software compatible with two or more Java interpreters.
2. Description of the Background Art
The Java programming language was developed in the early 1990's at Sun Microsystems, Inc., of Palo Alto, Calif. The goal was to provide a portable development environment for embedded systems. (An embedded system is a special-purpose computer-controlled system, such as a microprocessor controlling a microwave oven.) The plan was to provide a "Write Once, Run Anywhere" programming language, so that developers of embedded systems would not be tied to any particular CPU architecture.
The Java concept was developed and marketed to the embedded systems market, without great success. However, in the mid-1990's, the internet ("Web") underwent a period of explosive growth. (The terms "internet" and "Web" as used herein refer to a wide area data communications network, typically accessible by any user having appropriate software.) For the first time, people with various incompatible systems could access information remotely in a standard format. Web pages looked the same whether accessed from a workstation, PC, or Macintosh computer.
The next step was to provide more active content for Web pages, to provide more visual interest and to allow users to interact with the Web pages. Some sort of programming language support was clearly necessary. However, the language would have to be portable, i.e., it would have to execute on a variety of diverse computers using a variety of operating systems.
Java was the solution waiting in the wings for active content for the Web. Java was quickly embraced and introduced to literally millions of programmers. While much of the use of Java is for applets (i.e., small Java programs used by Web browsers) to enhance Web pages, Java is still a portable, general-purpose object-oriented programming language. Many programmers have traded in their C and C++ compilers for Java. However, compatibility issues have arisen relating to interfacing Java code to hardware or non-Java code.
Java, as the language is defined, is hardware independent. While this independence is a great benefit to most Java users, Java provides no mechanism for interfacing to an external device (typically either hardware or non-Java code). Unfortunately, in many instances, particularly in embedded design, it is necessary to communicate with device drivers, C or C++ libraries, or even the hardware itself.
Since Java is a hardware independent programming language, there must be a hardware dependent interface for each computer platform that will run the Java code. Commands such as "printer" and "write to disk" that make specific use of the hardware are handled through a platform-specific interpreter. To access non-standard hardware, or to access standard hardware in non-standard ways, native methods are used. Therefore, the current technique for communicating with hardware or non-Java software outside the standard functions provided by the interpreter is the native method. A "method" is a function or procedure. (The term "method" is also used herein in its traditional meaning of a series of steps performed to achieve a desired result.) A "native method" is a method that is platform dependent. To define a native method in Java, a method in a class is given the prefix "native". Java provides no implementation for native methods, but does supply a mechanism called a "native interface" for interfacing a native function definition to other code. The term "class" means a collection of data and methods that operate on the data. (Although the terms defined above are often used with reference to Java, the use of these terms herein is not intended to be restricted to Java.)
Sun Microsystems, Inc. supplied a first native interface in its version 1.0 Java Development Kit. The Sun 1.0 interface uses a technique involving "stubs"; therefore, this version is referred to herein as the Stubs interface. In version 1.1 of the Java Development Kit, Sun Microsystems, Inc. defined a second native interface called the Java Native Interface, or JNI. Finally, Microsoft Corporation has defined a third native interface for Java, known as Raw Native Interface, or RNI. The interpreters corresponding to these interfaces (Stubs, JNI, and RNI) are referred to herein as the Sun 1.0 interpreter, the Sun 1.1 interpreter, and the Microsoft Java interpreter, respectively.
The three interfaces are incompatible. As a consequence, when writing Java code using native methods a choice must be made whether to be compatible with the Stubs, JNI, or RNI interface. With this choice made, users of the code must also have the corresponding Java interpreter in order to execute the code. Clearly, this lack of standardization has adversely impacted the portability of Java. Since Java code is expressly designed for easy portability, it is desirable to provide a method for generating interface software compatible with two or more interpreters.